Facsimile transmissions (fax) are conventionally carried over circuits of the public switched telephone network (PSTN), in accordance with the T.30 protocol standardized by the International Telecommunications Union (ITU-T), which is incorporated herein by reference. Because of the high volume and high cost of sending faxes over the PSTN, there is increasing demand for fax services over packet networks, including fax over Internet Protocol (FoIP), frame relay and Asynchronous Transfer Mode (ATM) networks. A number of companies now offer services and equipment for fax transmission over packet networks, for example, Telogy Networks (www.telogy.com) and Miltel Telecommunication (www.milcoms.com).
FIG. 1 is a message flow diagram that schematically illustrates the essential elements of the T.30 protocol. The protocol is divided into five phases:                A. Call establishment—The sending fax terminal sends a calling tone (CNG), and the receiving fax terminal answers with a called terminal identification (CED).        B. Control and capabilities exchange—In this stage, the two terminals identify their capabilities and negotiate the conditions (such as data rate) of the call. The receiving terminal first sends a digital identification signal (DIS). The sending terminal responds with a digital command signal, defining the conditions of the call. It then initiates a training session with a training check field (TCF), to verify that the channel linking the calling and receiving terminals can carry the fax data at the intended data rate. The receiving terminal responds with a confirmation to receive (CFR) or a failure to train (FTT). In the case of an FTT, the training is repeated if possible, or else the call is terminated.        C. Page transfer—The sending terminal transmits a page of fax image data.        D. End of page and multi-page signaling—At the end of each page, the sending terminal sends a multi-page signal (MPS) if it has additional pages waiting to be sent, or an end of procedure (EOP) signal if there are no further pages. The receiving terminal responds with a message confirmation (MCF) to indicate that it received the page successfully and is ready to receive additional pages. Otherwise, the receiving terminal may send a retrain positive (RTP) or retrain negative (RTN) to indicate that retraining is needed before transmission can continue.        E. Call release—After receiving the last MCF from the receiving terminal, the sending terminal sends a disconnect (DCN) signal to the receiving terminal, and the call is concluded.Disconnection may also occur when training or retraining is unsuccessful or when there is a timeout due to one of the terminals failing to respond to a message within a predetermined period. Because the T.30 protocol was defined and developed for use on circuit-switched lines, the timeout periods are generally short and strictly enforced.        
The Internet Engineering Task Force (IETF) has proposed three possible models for fax over IP in Request for Comments (RFC) 2542, “Terminology and Goals for Internet Fax,” by L. Masinter, which is incorporated herein by reference:                “Store and forward”—The sending terminal sends the entire (multi-page) document to a staging point, or gateway, which stores the entire document before transmitting it to the destination. The sending terminal disconnects from the staging point without waiting for confirmation of delivery from the receiving terminal. This solution is efficient and inexpensive, but does not provide fax users with the confirmed delivery to which they are accustomed.        “Real-time”—This model enables two standard fax terminals to communicate over a packet network such that all of the essential elements of the T.30 protocol are preserved between the sending and receiving terminals.        “Session”—In this model, there is no requirement that the full T.30 protocol be maintained between the sending and receiving terminals, but delivery notification should be received at the sending terminal before disconnection.RFC 2542 does not address the question of how to achieve compatibility between these alternative models and the large base of installed fax machines, which require T.30 compliance in order to communicate. ITU-T has adopted Recommendation T.37 for store-and-forward FoIP, and Recommendation T.38 for real-time fax. These recommendations (available at www.itu.int/itudoc/itu-t/rec/t/t37.html and www.itu.int/itudoc/itu-t/rec/t/t38.html, respectively) are incorporated herein by reference. Session fax, however, has not been standardized.        
Real-time fax is closest conceptually to the T.30 model and can, in principle, be implemented in a straightforward way using suitable gateways or adapters to packetize communications between the sending and receiving terminals. In practice, however, real-time fax over actual packet networks, and particularly over IP networks, is problematic because of the strict timing constraints imposed by T.30. Unlike the PSTN, IP networks are characterized by jitter, lost packets, dynamic bandwidth changes and propagation delays that may result from third-party activities. As a result, when the network becomes at all congested, packet delays are liable to result in timeout and disconnection by the sending or receiving fax terminal.
A number of methods have been proposed to forestall timeout when packet delays occur in real-time packet fax transmission. These methods are based on spoofing the sending or receiving fax terminal. Typically, when expected messages or data do not arrive on time from one of the terminals, the gateway sends the other terminal spurious, fill bits or messages, such as command repeat (CRP) signals asking the terminal to resend the last message. Methods of spoofing in the context of real-time digital fax are described, for example, in U.S. Pat. No. No. 5,828,468, whose disclosure is incorporated herein by reference. Even with spoofing capabilities, however, real-time fax is demanding of network resources and will fail when there is a packet delay of more than a few seconds, as may easily occur in a congested IP network.